1. Field of the Invention
The present invention relates to a computer system, and deals more particularly with a method, system, and computer program product for providing a piggy-backed key exchange protocol. This protocol is used between a client and server to establish security parameters that used to exchange data in a secure manner. By piggy-backing the key exchange onto other messages, the overhead associated with setting up a secure browser connection is reduced.
2. Description of the Related Art
Traditionally, complex distributed applications have been designed around the client/server paradigm, where the application logic is split into two integral parts. One of the parts provides the client functionality, and the other provides the server functions. Each of the parts is then installed on the respective hardware. Such an architecture has the fundamental drawback that the application usually must be tailored around a particular user device and vice versa: the application must function on the particular hardware and software profile of the intended user device, and the user device must meet the application requirements in terms of form-factor, processor requirements, storage capabilities, etc. This coupling leads to the implementation of the client functionality being fundamentally tied to a single type or class of end-user device. The client implementation typically must be modified in order to operate on different devices or operating system platforms, and separate versions must be provided to address the inherent differences in the devices and platforms. This leads to increased complexity and expense for application development and testing, distribution and support, etc. Because of the proliferation in client device types, it is becoming increasingly demanding to provide applications that reliably meet the constraints imposed by the different device types. This proliferation also creates a greater burden on end users who must similarly obtain and manage different versions of their application software, one for each type of device.
In the face of these challenges, there is a clear trend toward delivering applications to users in a form that is accessible via a more standard infrastructure that is available on most hardware and operating system platforms. One type of standard infrastructure is the browser. (Note that the browser implementation itself is generally non-portable, but the intent is to have the browser represent the only platform-specific code that developers write and that end users must deploy.) Within this standard infrastructure, application-specific content may be retrieved and presented to the user. Moreover, application-specific logic may be executed within an appropriate scripting environment provided on the client side by most browsers, including Netscape Navigator(copyright) and Internet Explorer. (xe2x80x9cNetscape Navigatorxe2x80x9d is a registered trademark of Netscape Communications Corporation.) On some devices, the scripting environment may be separate from the browser, and may support richer (though still portable) application logic such as those applications written in the Java programming language. (xe2x80x9cJavaxe2x80x9d is a trademark of Sun Microsystems, Inc.)
The trade off that comes from making the client infrastructure standard, however, is that it is also generic. That is, while the infrastructure is not written for the needs of a particular client application, it is able to act as the client for a wide range of applications. In this generic client environment, the problem of implementing each application shifts primarily toward the server side. (Hereinafter, the term xe2x80x9cbrowserxe2x80x9d will be used to refer to the generic client software, including the associated scripting and application environment(s).) This, in turn, somewhat complicates the tasks that must be implemented in the server software, as the server software must adapt the content to match the capabilities of the particular browser executing on the client. Alternatively, the burden may be shifted to one or more computers in the delivery chain between the client and server. In particular, a variety of transcoders and gateways can be envisaged in this delivery chain. Each of these transcoders and gateways may potentially have knowledge of a target client device""s particularities, which the transcoder or gateway can then use to adjust data generated by a server application that is being delivered to this client. The Wireless Application Protocol, or xe2x80x9cWAP,xe2x80x9d is an example of an application architecture which may employ this type of multiple transcoder and multiple gateway environment.
In such an environment where data is being transmitted between a client and server while passing through intermediate transcoders or gateways, data security is often a key concern. A client may need to send data to the server that is considered security-sensitive by the client or the server, such as when a person""s credit card information is transmitted through a network for use by an electronic shopping application executing on the server. In addition, the content dispatched from the server to the client is often considered security-sensitive. A simple example of this situation is the same electronic shopping application just discussed, where the server may transmit an order confirmation to the client that includes the client""s credit card information. Many other security-sensitive transmissions exist, such as those that occur when using electronic banking, online stock trading, online bill presentment and payment, etc. The problems that may ensue when sensitive data is exposed to an unintended recipient, such as a computer hacker, can be quite serious. While gateways, and transcoders in particular, may be designed to modify the application content in legitimate ways when forwarding it through the delivery chain, sensitive content at the same time must not be disclosed to such intermediaries. (U.S. patent application Ser. No. 09/352,534, which is titled xe2x80x9cMethod for Transmitting Information Data from a Sender to a Receiver via a Transcoder, Method of Transcoding Information Data, Method for Receiving Transcoded Information Data, Sender, Transcoder, and Receiverxe2x80x9d and is assigned to the same assignee, defines a novel technique for use in such an environment where the security-sensitive portions of a Hypertext Markup Language, or HTML, document are encrypted while leaving the portions in plain text.
A number of security protocols have been developed for use in client/server and other networking environments. Examples include the SSL (Secure Sockets Layer), TLS (Transport Layer Security), and WTLS (Wireless Transport Layer Security) protocols. (TLS is being defined by the Internet Engineering Task Force as a follow-on replacement for SSL, and WTLS is being developed by the WAP Forum as a security protocol optimized for the mobile computing environment.) These protocols all share the characteristic of encrypting all data transmitted through a network connection or communication session, thereby preventing an intermediary, such as a transcoder, from inspecting and/or modifying any of the data being exchanged. Consequently, these transport-based security protocols are ineffective in environments having transcoders and gateways that must legitimately modify and therefore inspect some non-security-sensitive sections of the data stream.
To enable intermediaries to perform legitimate content modifications, end-to-end security in a complex delivery chain such as that described above must be provided at the application layer (referred to equivalently as the xe2x80x9capplication levelxe2x80x9d) of the client and server. This means that security-related functions such as encryption, decryption, and authentication are performed under control of the application software, as only the application is able to distinguish between content that can be transmitted in plaintext (i.e. can be exposed to and acted upon by intermediaries) and content that is security sensitive and must be protected end-to-end (i.e. cannot be exposed to or acted upon by intermediaries). When application-level security is employed, the application invokes the services of specialized security software or tools to perform encryption, decryption, and authentication. Once the sensitive data has been encrypted at the application level, lower-layer functions of the system (such as the communications protocol stack, which is responsible for packetizing the content into messages, transmitting those messages to the destination, and re-assembling those messages into the original content) are unable to decrypt and modify that data. More importantly, such sensitive data also cannot be decrypted by the intermediate computers in the delivery chain, since these computers neither execute the application-level code shared by the client and server nor have access to the security keys and credentials used to encrypt the data. Similarly, the raw data corresponding to the encrypted content is not visible to hackers who might try to intercept it.
While an end-to-end security session established at the application layer provides advantageous security protection in the manner described above (i.e., allowing the secure exchange of information between application endpoints without being subject to decryption and/or modification by network intermediaries or hackers), application-layer security also imposes several drawbacks. First, a number of message exchanges may occur before a suitable set of parameters can be agreed upon. For example, security protocols require a key exchange phase where the client and server exchange and negotiate parameters such as the cipher suite and session key to be used during this security session. While this may be of little consequence when using high bandwidth, relatively inexpensive connections such as those provided in local area networks or the wired Internet, each message transmitted in a wireless environment such as SMS (Short Message Services) or USSD (Unstructured Supplementary Services Data) carries a rather high cost to the user. Thus, establishing the secure application-level session can be an expensive operation. Second, the message exchanges used to establish secure sessions are not easily encapsulated within existing application-layer protocols. These protocols consist of an already-defined set of primitives for communication between the client and server applications, and it is usually impossible to introduce the additional protocol primitives required for an application-level security parameter negotiation.
Accordingly, what is needed is a technique for establishing and maintaining end-to-end security sessions at the application level while maintaining the integrity of any application-layer communications protocol and without adding undue amounts of communications and message exchanges.
An object of the present invention is to provide a technique whereby a secure session can be established between a client browser and a server.
Another object of the present invention is to provide this technique whereby a minimal number of message exchanges are required to establish the secure session.
A further object of the present invention is to provide this technique whereby the session uses application-level security.
Yet another object of the present invention is to provide this technique whereby the integrity of any application-layer communications protocol is maintained.
A further object of the present invention is to provide this technique in a manner that is adaptable to a number of different client/server environments.
A further object of the present invention is to provide this technique using existing communication protocol messages.
Still another object of the present invention is to provide this technique when a server will not use a message encoding scheme proposed by a client.
Other objects and advantages of the present invention will be set forth in part in the description and in the drawings which follow and, in part, will be obvious from the description or may be learned by practice of the invention.
To achieve the foregoing objects, and in accordance with the purpose of the invention as broadly described herein, the present invention provides a method, system, and computer program product for use in a computing environment having a connection to a network, for establishing a secure, low-overhead connection between a client application (such as a browser) and a server application using existing message types. In one embodiment, this technique comprises: piggy-backing a first portion of security information onto a first message sent from the client application to the server application, wherein the first message uses a first existing message type; piggy-backing a second portion of security information onto a second message sent from the server application to the client application, wherein the second message uses a second existing message type; piggy-backing a third portion of security information onto a third message sent from the client application to the server application, wherein the third message uses the first existing message type; and piggy-backing a fourth portion of security information onto a fourth message sent from the server application to the client application, wherein the fourth message uses a third existing message type.
The first existing message type may be a HyperText Transfer Protocol (HTTP) or a Wireless Session Protocol (WSP) GET message, in which case the third existing message type is a response to the HTTP or WSP GET message. Or, the first existing message type may be an HTTP or a WSP POST message, in which case the third existing message type is a response to the HTTP or WSP POST message. The second existing message type may be an HTTP or WSP REDIRECT message, or a www-Authenticate message.
The server application will not use a message encoding scheme proposed by the client application. In a first aspect, the first message requests a secure page from the server application, wherein the request further comprises an identifier of the secure page; the second message sends a redirection message from the server application to the client application, wherein the redirection message comprises a redirected identifier of the secure page; the third message sends a subsequent request for the secure page from the server application in response to the redirection message, wherein the subsequent request further comprises the redirected identifier of the secure page; and the fourth message sends a response to the subsequent secure page request to the client application, wherein the response further comprises a content portion encrypted using a session key generated by the server application. In a second aspect, the second message sends an authentication message from the server application to the client application instead of sending the redirection message, and the third message sends a subsequent request for the secure page from the server application in response to this authentication message. The authentication message may comprise a redirected identifier of the secure page, and the subsequent request further may comprises this redirected identifier.
In both aspects, the first portion may further comprise a first set of information encrypted using a public key of a trusted third party (TTP); the second portion may further comprise a security certificate or an identifier of the server; the third portion may further comprise a second set of information encrypted using a public key of the server; and the response may further comprises a nonce of the server application, encrypted using a public key of the client application.
The first set of information preferably comprises: zero or more parameters required for the secure page request; an identification of the client application; an identification of the server application; an identification of the TTP; a client nonce; and optionally including a timestamp. The second set of information preferably comprises: zero or more parameters required for the subsequent secure page request; the identification of the client application; the client nonce; and the timestamp when the first set includes the timestamp.
Or, the first set of information may be encrypted using the public key of the server application or a session key known to the client application instead of using the public key of the TTP. In this case, the first set of information omits the identification of the server application and the identification of the TTP.
The redirected identifier of the secure page may be identical to the identifier of the secure page.